One limitation of conventional dynamic trick play generation is that the view files reference only a sub-set of the I-frames present in the source MPEG content. That makes disk I/O very inefficient, especially on systems based on RAID volumes when one of the data disks is off-line. For example, if I-frames occur every 0.5 second on a 4 Mbps stream, then a full stripe read of a 5+1 RAID array with a 512 kb block size will yield only about 10 I-frames. Only a fraction of those are actually useful when constructing trick play view files with greater than 1× playback rates. For example, if I-frames are on average 50 kb and the desired trick play speed uses only 5 I-frames from a RAID stripe, the effectiveness of the data read is only (5*50 kb)/(5*512 kb), which is less than 10%.
Under normal conditions (e.g. where no RAID reconstruction is required) it is not necessary to read the full stripe in order to obtain the desired I-frames. In the best case, a full disk block read is required, while in the worst case may involve reading two disk blocks when an I-frame spans blocks.
Another limitation of conventional dynamic trick play generation is that the source MPEG content usually includes several independent media streams. Trick play view streams need to be fully compliant MPEG-bitstreams, but simple cut-and-past operations on I-frames could produce non-contiguous bitstreams. A solution used in the past was the insertion of transport stream discontinuity indicators between each pair of I-frames, however some set top boxes do not handle discontinuities correctly. Another approach used in the past was to perform filtering in real time so that the unwanted media streams could be excluded. That adds significant overhead to the real time processor, because the unwanted packets have to be located, and the I-frame fragments need to be reassembled.
The limitations above motivated the development of multi-asset trick play mechanisms where all allowable trick play speeds were pre-generated as part of the content ingest mechanism. Some drawbacks of multi-asset trick play mechanisms are the lack of flexibility (can only use the pre-generated trick play speeds) and the need for extra storage space for all trick play files generated. Also, in the network DVR scenario with real time playback requirements, efficient disk I/O and latency from live feed are conflicting objectives. The network DVR process must record not only the main view data, but also all the required trick play view files. Because trick play view data is generated more slowly, the network DVR process must write partial blocks/stripes in order to ensure availability of live data, which increases the disk I/O bandwidth utilization and imposes extra processing load on the system.